The present invention relates generally to data communication systems and more particularly, to a method of improving notification and handling of device status changes in MPOA enabled ATM based networks.
The majority of networks, e.g., IP networks, are constructed from a plurality of nodes grouped together to form one or more subnets. Subnets are often built using various LAN technologies, with Ethernet and Token Ring being the most popular. Nodes in different subnets cannot normally communicate with each other. A router permits a node in one subnet to communicate with a node on a different subnet. Most internetwork layer protocols utilize routers to permit communications across subnet boundaries.
LAN Emulation (LE), as defined by the ATM Forum, provides Emulated LANs (ELANs) which emulate the services of Ethernet and Token Ring LANs across an ATM network. LE allows a subnet to be bridged across an ATM/LAN boundary. LE permits a single ATM network to support multiple ELANs. Utilizing ELANs, internetwork layer protocols can operate over an ATM network in essentially the same way they operate over Ethernet or Token Ring LANs. Although LE provides an effective means for bridging intra-subnet data across an ATM network, inter-network traffic still must be forwarded through routers.
The Next Hop Resolution Protocol (NHRP) and Multicast Address Resolution Server (MARS) protocols defined by the Internetworking Over NBMA (ION) Working Group, also permit internetwork layer protocols to operate over an ATM network. These protocols permit the ATM network to be divided into multiple ION subnets, also known as Logical IP Subnets (LISs) or Local Access Groups (LAGs). Routers are required, however, to interconnect these subnets. NHRP, however, allows intermediate routers to be bypassed on the data path. NHRP provides an extended address resolution protocol that permits Next Hop Clients (NHCs) to send queries between different subnets. Queries are propagated by Next Hop Servers (NHSs) along the routed path as determined by standard routing protocols. This enables the establishment of ATM VCCs across subnet boundaries, permitting inter-subnet communication without requiring routers in the data path.
Notwithstanding the availability of LANE and NHRP, a common situation exists wherein communicating LAN devices are behind LANE edge devices. The use of Multi-Protocol Over ATM (MPOA) permits these edge devices to perform internetwork layer forwarding and establish direct communications without requiring that the LANE edge devices comprise full function routers.
MPOA functions to provide an efficient transfer of inter-subnet unicast data in a LE environment. MPOA integrates LE and NHRP so as to preserve the benefits of LE, while allowing inter-subnet, internetwork layer protocol communication over ATM VCCs without requiring routers in the data path. MPOA provides a framework for effectively synthesizing bridging and routing with ATM in an environment of diverse protocols and network technologies. This framework provides a unified paradigm for overlaying internetwork layer protocols on ATM. MPOA is capable of using both routing and bridging information to select a shortcut through the ATM cloud to the egress MPC.
MPOA permits the physical separation of internetwork layer route calculation and forwarding, a technique known as virtual routing. This separation has the advantages of: (1) allowing efficient inter-subnet communications; (2) increasing manageability by decreasing the number of devices that must be configured to perform internetwork layer route calculation; (3) increases scalability by reducing the number of devices participating in internetwork layer route calculation; and (4) reduces the complexity of edge devices by eliminating the need to perform internetwork layer route calculation.
MPOA provides MPOA Clients (MPCs) and MPOA Servers (MPSs) and defines the protocols that are required for MPCs and MPSs to communicate. MPCs function to issue queries for shortcut ATM addresses and to receive replies from the MPS using these protocols. MPOA also functions to ensure interoperability with the existing infrastructure of routers. MPOA Servers utilize routers that run standard internetwork layer routing protocols, e.g., Open Shortest Path First (OSPF), providing a smooth integration with existing networks.
The primary function of the MPC is to source and sink internetwork shortcuts. The MPC performs internetwork layer forwarding but does not run internetwork layer routing protocols. The MPC detects ingress flows of packets that are forwarded over an ELAN to a router that comprises an MPS. When it recognizes a flow that could benefit from a shortcut that bypasses the routed path, it uses an NHRP based query/response protocol to request the information required to establish a shortcut to the destination. If a shortcut is available, the MPC caches the information in its ingress cache, sets up a shortcut VCC and forwards frames for the destination over the shortcut.
The MPC receives egress internetwork data frames from other MPCs to be forwarded to its local interface and/or users. For frames received over a shortcut, the MPC adds the appropriate encapsulation/header and forwards them to the higher layers. The encapsulation is provided to the MPC by the egress MPS and stored in the egress cache in the MPC. Note that an MPC is able to service multiple LECs and communicates with multiple MPSs. In addition, there may be multiple MPCs in an edge device. A given LEC, however, may be associated with only a single MPC.
An MPS is the logical component of a router that provides internetwork layer forwarding information to the MPCs. It comprises a full NHRP implementation with extensions as defined in the ATM Forum Multi-Protocol Over ATM Specification Version 1.0, AF-MPOA-0087.000, July 1997, incorporated herein in its entirety by reference. The MPS interacts with its local NHS and routing functions to reply to MPOA queries from ingress MPCs and provides encapsulation information to egress MPCs. Note that an MPS converts between MPOA requests and replies and NHRP requests and replies on behalf of MPCs. In addition, there may be multiple MPSs in a router. A given LEC, however, may be associated with only a single MPS.
An MPOA solution generally comprises a plurality of MPOA control flows and MPOA data flows. All control and data flows are carried over ATM VCCs. Control flows use MPOA control VCCs. Note that these VCCs can be used for other protocols (e.g., LE, etc.) as well in a multiplexed mode. Data flows, on the other hand, are carried over either LE VCCs (i.e., the default path) or over shortcut VCCs established via MPOA.
MPOA performs the following operations: configuration, discovery, target resolution, connection management and data transfer. Configuration includes obtaining the appropriate configuration information in both MPC and MPS. Normally, MPOA components receive configuration information from the LECS. Discovery involves MPCs and MPSs learning of each other""s existence. MPOA components automatically discover each other using extensions to the LE LE ARP protocol that carry the MPOA device type (i.e., MPS, MPC) and ATM address. This information may change and must be periodically verified and updated if necessary. An MPOA device type TLV can be included in the following LE messages: LE_REGISTER request and response, LE ARP request and response and targetless LE_ARP request.
Target resolution denotes the determining of the mapping of a target to an egrss ATM address, an optional tag and a set of parameters used to setup a shortcut to forward packets across subnet boundaries.
Connection management entails creating, maintaining and terminating VCCs for the purpose of transferring control information and data. MPOA components establish VCCs between each other as necessary to transfer control and data messages over the ATM network. The goal of MPOA is the efficient transfer of unicast data within the ATM cloud. Unicast data flow can comprise either the default flow or the shortcut flow. The default flow follows the routed path over the ATM network whereby the MPOA edge device functions as a layer 2 bridge. Shortcuts are established using the MPOA target resolution and cache management mechanisms. When an MPC has an internetwork protocol packet to send for which it has a shortcut, the MPOA edge device functions as an internetwork level forwarder and sends the packet over the shortcut.
A block diagram illustrating an example MPOA network comprising a plurality of MPSs and MPCs wherein the default path and shortcut path are highlighted, is shown in FIG. 1. The network, generally referenced 10, comprises a source end station 22, plurality of MPCs 12, labeled MPC #1 and #2, a plurality of ELANs 14, a plurality of MPSs 16, labeled MPS #1 and #2, destination end station 24 and ATM cloud 26. The default path is represented by dashed arrow 18 while the shortcut is represented by solid arrow 20.
The ingress MPC (e.g., MPC #1) learns the MAC addresses of the MPSs (e.g., MPS #1) attached to its ELANs from the device type TLVs in LE_ARP responses. The MPC performs flow detection, based on internetwork layer destination addresses, on packets destined for these learned MAC addresses. Although default forwarding is via routers, if an MPC becomes aware of a particular traffic flow that might benefit from a shortcut, the ingress MPC then determines the ATM address associated with the egress device. The ingress MPC sends an MPOA Resolution Request message to the appropriate ingress MPS in order to obtain the ATM address for a shortcut. The MPS resolves the MPOA Resolution Request and a reply is returned to the ingress MPC containing the ATM address of the egress device.
The ingress MPS processes MPOA Resolution Requests sent by local MPCs. It may answer the request if the destination is local or it may re-originate the request along the routed path through its local NHS.
When an NHRP Resolution Request targeted for a local MPC arrives at the egress MPS serving that MPC, the egress MPS sources an MPOA Cache Imposition Request and sends it to the egress MPC. This request is part of the cache management protocol that serves to provide encapsulation and state maintenance information needed by the egress MPC (e.g., MPC #2). The corresponding reply provides status, address and ingress tagging information needed by the egress MPS (e.g., MPS #2) in forming the NHRP Resolution Reply.
The egress MPC (e.g., MPC #2) checks to determine whether it has sufficient resources to maintain the cache entry and potentially receive a new VCC and replies accordingly. The Egress MPS sends an MPOA Cache Imposition Reply for every MPOA Cache Imposition Request.
With reference to FIG. 1, a packet generated by the source end station enters the MPOA system at the ingress MPC (MPC #1). The MPC creates a new cache entry for new flows that are detected. If a valid shortcut does not already exist for the flow, the MPC begins counting frames. When a threshold is exceeded, a MPOA Resolution Request is sent to the MPS to request a shortcut. By default, the packet is bridged via LE to a router. If the packet is not to follow the default path, i.e., it is part of a flow for which a shortcut has previously been established, it is sent via the shortcut. If the packet comprises a new flow, each packet sent to an MPS is logged and counted (by internetwork layer destination address) as it is being sent via LE. When a threshold (a number of packets within a given period of time) is exceeded, the MPC sends an MPOA Resolution Request to obtain the ATM address to be used for establishing a shortcut to a particular downstream element (e.g., an egress MPC).
When the packet arrives at the egress MPC (e.g., MPC #2) via the shortcut, it is examined and either a matching egress cache entry is found or the packet is dropped and an error is indicated. If a match is found, the packet is encapsulated using the information in the egress cache and then forwarded to a higher layer.
As described previously, the MPOA standard includes a mechanism for automatically discovering other devices in a dynamic manner. More specifically, an MPOA device is uniquely identified by its control ATM address that is discovered by neighboring MPOA devices. Note that it is important for MPOA Clients to have knowledge of the MAC and ATM addresses of the local MPOA Servers in order that MPOA requests may be sent. Further, the MPOA Server must know if an NHRP request resolved to the ATM address of an MPOA Client so that a cache imposition may be sent. In addition, MPOA Servers that share an ELAN must be able to discover the existence of each other in order to facilitate the forwarding of NHRP messages.
To accomplish the above requirements, the MPOA discovery process is based on the mechanism provided for by LANE messaging which has been extended with MPOA Device Type TLVs (Type, Length, Value), e.g., LE_ARP control frames.
In addition, an MPOA device should notify its neighboring MPOA devices about changes to the device""s xe2x80x98Device Status Configurationxe2x80x99 that each device is aware of and is maintained internally. Such changes include, for example, a device changing its configuration to enable or disable an MPOA Server or Client associated with a LEC, or to disassociate a LEC from an MPOA Server or Client.
Currently, the prior art provides the following ways to notify other MPOA aware devices of changes in the configuration of an MPOA Server or Client or associated LEC device. In a first way, a LEC or MPOA Server or Client may terminate its membership in an ELAN and/or cease operations for a period of time that is longer than the maximum LE_ARP time-out period. The maximum LE_ARP time-out period is specified to be five minutes in the ATM Forum LANE Version 1.0 and 2.0 standards which is a relatively long time in the context of a network.
An advantage of this technique is that it is reliable. Once the time period has passed, the change will be detected with a high degree of probability. The disadvantages, however, are that all network traffic to and from the ELAN ceases for a relatively long time, e.g., five minutes. The ELAN must wait the entire five minutes (i.e., until the LE_ARP cache time out) before the device""s neighbors discover the change in status. In addition, when the LEC becomes operational again, there is a sharp surge in network traffic from the traffic that was waiting to be sent during the period of time the LEC was not operational. This creates a traffic load with the potential to create congestion and bottlenecks in the network.
In a second way of notifying other MPOA devices of the changes in configuration, a LEC sends one or more targetless LE_ARP_REQUEST messages (via TLV extensions) so as to update the MPOA Server or Client associations of other LECs. The advantages of this technique are that the traffic load is minor and there is no waiting time with the subsequent surge in network traffic. The absence of a network disturbance is offset, however, by decreased reliability in that there is no ACK message to ensue delivery and acceptance of the LE ARP REQUEST message. There is no certainty that the message reached its intended target. For example, in the case when the message is delivered via the LAN Emulation Server (LES), if the LES is congested at that time it may drop the frame. Thus, the target LEC may never receive the message.
In a third way of notifying other MPOA devices of the changes in configuration, an MPOA Server or Client responds to an MPOA request with an error code that indicates xe2x80x98this device is no longer an MPOA Server (or Client)xe2x80x99. The error codes to indicate this are defined in the ATM Forum MPOA standard in Section 4.2.4. This technique has an advantage in that there is no waiting time and no consequent disturbance to the network. On the other hand, however, a disadvantage is that this creates a conflict in that the other MPOA Servers and Clients in the network do not receive this notification. The other devices in the network continue to consider this device to be an MPOA Server or Client.
In addition, another disadvantage is the late response of neighbor devices to status changes resulting in potentially high traffic loads. In some cases, this results in more traffic generated than if the device did not return an error code. Further, another disadvantage is that this technique only addresses the case when a device is no longer an MPOA device. In other words, the technique is only applicable to the case when a device was previously an MPOA device and is currently not an MPOA Server or Client anymore. This, however, represents only one possible type of device status change as there are many others that may occur.
The present invention is a method of notification and handling of device status changes in MPOA enabled ATM based networks. The present invention comprises two methods an MPOA device can utilize to notify changes about its device status configuration. The first method is based on the release of LANE data direct VCs (DDVCs) previously established between LECs. The second method is based on each MPOA device periodically sending keep alive or similar messages.
The first method provides notification of changes in device status configuration by selectively releasing one or more Data Direct VCs tat were previously established between LECs connecting MPOA Servers and MPOA Clients. An MPOA Server, upon detecting a change to its device configuration status, releases the Data Direct VCs connecting its associated LEC to other LECs associated with known MPSs and MPCs that are neighbors to it. All MPOA devices for which a Data Direct VC was released, delete all LE_ARP cache entries associated with the ATM destination of the released Data Direct VC. Further, an MPC, upon detecting a change to its device configuration status, releases the Data Direct VCs connecting its associated LEC to other LECs associated with known MPSs.
In the second method, each MPOA device adapted to perform the method of the present invention, periodically sends out keep alive messages to neighboring MPOA devices. The keep alive message is preferably a targetless LE_ARP message. This message comprises the standard MPOA identification TLV and a new MPOA-VALID TLV that indicates the validation time-out period for that entry. A validation time-out field is added to each entry in the LE_ARP cache table to indicate the time remaining to maintain a valid entry. An MPOA device receiving the keep alive message, refreshes (i.e., restarts) a validation timer for each association made by the corresponding MPOA identification TLV. If the validation timer expires before being refreshed, the MPOA device deletes all associations previously made by the corresponding MPOA identification TLV.
Note that if an MPOA device that is not adapted to perform the method of the present invention receives a message with the MPOA-VALID TLV, it ignores the message and operates in accordance with the MPOA standard.
There is provided in accordance with the present invention, in an Asynchronous Transfer Mode (ATM) based Multiple Protocol Over ATM (MPOA) network running LAN Emulation (LE), a method of notifying devices in the network of changes in device configuration status, the method comprising the steps of detecting changes in device status configuration in an MPOA device, releasing all LE Data Direct VCs (DDVCS) to all LAN Emulation Client (LEC) ATM addresses associated with known MPOA Server and MPOA Client neighbors, if the MPOA device comprises an MPOA Server, releasing all LE Data Direct VCs (DDVCs) to all LEC ATM addresses associated with known MPOA Server neighbors, if the MPOA device comprises an MPOA Client and deleting all table entries associated with LEC ATM destination addresses of released DDVCs in an MPOA device for which a DDVC was released.
The step of detecting may comprise the step of detecting the starting of an MPOA Server; the stopping of an MPOA Server, the starting of an MPOA Client, the stopping of an MPOA Client, the starting of a LEC associated with an MPOA device, the stopping of a LEC associated with an MPOA device, the association of a LEC with an MPOA device or the de-association of a LEC with an MPOA device.
There is further provided in accordance with the present invention, in an Asynchronous Transfer Mode (ATM) based Multiple Protocol Over ATM (MPOA) network running LAN Emulation (LE), a method of notifying devices in the network of changes in device configuration status, the method comprising the steps of associating a validation time-out field with each MPOA device type TLV associated with a LAN Emulation Client (LEC) ATM address and registered within each MPOA device, periodically sending a keep alive message to neighboring MPOA devices, receiving the keep alive message by an MPOA Server or Client and in response thereto, restarting a validation timer corresponding to a validation time-out field associated with a registered MPOA device type TLV and deleting an MPOA device type TLV entry corresponding to a LEC ATM address whose validation timer expires before a refresh of the validation timer is received.
The keep alive message comprises a targetless LE_ARP message having a standard MPOA Type, Length, Value (TLV) and an MPOA-VALID TLV specifying the value T2 of the validation time-out field. Alternatively, the keep alive message comprises a targetless LE_ARP message having a standard MPOA Type, Length, Value (TLV) and an MPOA-VALID TLV specifying the value T2 of the validation time-out field whereby T2 is given by T2=N1xc3x97T1, whereby T1 is represents the time between the sending of the keep alive messages and N1 is a positive integer.